Events communicate information about user actions, changes in the processing status of an application and other occurrences that may require response from an application. For example, events include, but are not limited to, user input, system messaging events which are messages to an application and generated by the operating system, and interapplication events which communicate between co-existing applications.
Events which are directed to human interface elements are typically referred to as human interface events (“HI events”). Examples of human interface elements include, but are not limited to, windows, panels, editable text, push buttons, list boxes, radio buttons, etc.
Generally, event loops are used to process events. Typically, the inside of the loop is structured to determine the kind of event and then to branch to code to handle that particular kind of event. The kind of event is generally hard-coded into the event loop. For example, a line of code might read:
if (event == mouse_down)then call handle_mouse_down;else if (event == keyboard_click)then call handle_keyboard click;
Such systems have several disadvantages. First, there is generally no mechanism for explicitly adding new kinds of events without actually editing the code of the programming structure. Changing the code generally requires recompiling and building of the program and is thus undesirable.
Second, since the sequence performed in checking the kind of event is statically defined, applications may check for events in which there is no interest. For example, a particular application may be interested in mouse events, but not keyboard events. Even so, if the keyboard events precede mouse events in the checking sequence, the application will waste resources checking whether the event is a keyboard event.
Third, this style of event dispatching architecture tends to be either limiting or inefficient when arbitrary components may be inserted into an application. For example, an application may allow third parties to provide custom plugins. Such a plugin might be interested in an event that the application does not itself use. Typically, an application will either (a) not pass the event to the plugin, in which case the plugin cannot react to it, or (b) pass all unhandled events to every plugin, even if a given plugin is not interested in a particular event, leading to greater overhead and slower performance during event dispatching.
Similarly, in a window/root panel/subpanel windowing architecture, a subpanel may recognize an event that a parent panel does not. The parent panel is required to pass an event it doesn't recognize to one of its subpanels.